Fast update of data packet checksums

ABSTRACT

A device includes a processor and a checksum module, wherein the checksum module calculates, for first data, an updated checksum that complies with Internet Engineering Task Force Request For Comments Number 1624 using twos-complement arithmetic. The processor replaces the original checksum with the updated checksum to update a data packet.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation and claims the priority benefit ofU.S. patent application Ser. No. 14/521,035 filed Oct. 22, 2014, nowU.S. Pat. No. 9,698,825 the disclosure of which is incorporated hereinby reference.

FIELD OF THE DISCLOSURE

This disclosure generally relates to information handling systems, andmore particularly relates to fast updates of data packet checksums.

BACKGROUND

As the value and use of information continues to increase, individualsand businesses seek additional ways to process and store information.One option is an information handling system. An information handlingsystem generally processes, compiles, stores, and/or communicatesinformation or data for business, personal, or other purposes. Becausetechnology and information handling needs and requirements may varybetween different applications, information handling systems may alsovary regarding what information is handled, how the information ishandled, how much information is processed, stored, or communicated, andhow quickly and efficiently the information may be processed, stored, orcommunicated. The variations in information handling systems allow forinformation handling systems to be general or configured for a specificuser or specific use such as financial transaction processing,reservations, enterprise data storage, or global communications. Inaddition, information handling systems may include a variety of hardwareand software resources that may be configured to process, store, andcommunicate information and may include one or more computer systems,data storage systems, and networking systems.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration,elements illustrated in the Figures have not necessarily been drawn toscale. For example, the dimensions of some of the elements areexaggerated relative to other elements. Embodiments incorporatingteachings of the present disclosure are shown and described with respectto the drawings presented herein, in which:

FIG. 1 illustrates a private network according to an embodiment of thepresent disclosure;

FIGS. 2 and 3 illustrate a method of determining IP, TCP, and UDP packetchecksum updates in accordance with ITEF RFC 1624;

FIGS. 4 and 5 illustrate a method of determining IP, TCP, and UDP packetchecksum updates according to an embodiment of the present disclosure;and

FIG. 6 is a block diagram illustrating a generalized informationhandling system according to an embodiment of the present disclosure.

The use of the same reference symbols in different drawings indicatessimilar or identical items.

DETAILED DESCRIPTION OF DRAWINGS

The following description in combination with the Figures is provided toassist in understanding the teachings disclosed herein. The followingdiscussion will focus on specific implementations and embodiments of theteachings. This focus is provided to assist in describing the teachings,and should not be interpreted as a limitation on the scope orapplicability of the teachings. However, other teachings can certainlybe used in this application. The teachings can also be used in otherapplications, and with several different types of architectures, such asdistributed computing architectures, client/server architectures, ormiddleware server architectures and associated resources.

FIG. 1 illustrates an embodiment of a private network 100 which is anexample of an information handling system. For the purpose of thisdisclosure an information handling system can include anyinstrumentality or aggregate of instrumentalities operable to compute,classify, process, transmit, receive, retrieve, originate, switch,store, display, manifest, detect, record, reproduce, handle, or utilizeany form of information, intelligence, or data for business, scientific,control, entertainment, or other purposes. For example, an informationhandling system can be a personal computer, a laptop computer, a smartphone, a tablet device or other consumer electronic device, a networkserver, a network storage device, a switch router or other networkcommunication device, or any other suitable device and may vary in size,shape, performance, functionality, and price. Further, an informationhandling system can include processing resources for executingmachine-executable code, such as a central processing unit (CPU), aprogrammable logic array (PLA), an embedded device such as aSystem-on-a-Chip (SoC), or other control logic hardware. An informationhandling system can also include one or more computer-readable mediumfor storing machine-executable code, such as software or data.Additional components of an information handling system can include oneor more storage devices that can store machine-executable code, one ormore communications ports for communicating with external devices, andvarious input and output (I/O) devices, such as a keyboard, a mouse, anda video display. An information handling system can also include one ormore buses operable to transmit information between the various hardwarecomponents.

Private network 100 includes a Network Address Translation (NAT) router110 and client systems 120, 122, and 124. NAT router 110 providesInternet Protocol (IP) masquerading to hide the IP address space ofclient systems 120, 122, and 124 from a public network 130. As such, NATrouter 110 sets up a private network with a hidden IP address space thatis hidden behind a single IP address in the IP address space of publicnetwork 130. For example, public network 130 can represent the Internet,upon which NAT router 110 is identified by a public IP address, such as143.166.147.7, and the NAT router can establish a private subnet, suchas 192.168.100.x, establishing itself as the default gateway for theprivate subnet, such as 192.168.100.1. Here, clients 120, 122, and 124are each assigned IP addresses on the private subnet, such as192.168.100.2 for client 120, 192.168,100.3 for client 122, and192.168.100.4 for client 124. In a particular embodiment, the IPaddresses of clients 120, 122, and 124 are static IP addresses that areprovided on the clients and NAT router 110. In another embodiment, theIP addresses of clients 120, 122, and 124 are provided to the clientsfrom NAT router 110 when the clients are connected to the NAT router,such as via a local area network (LAN) or wireless LAN. Here, NAT router110 can implement the Dynamic Host Configuration Protocol (DHCP) toassign clients 120, 122, and 124 their respective IP addresses when theyare connected to the NAT router.

NAT router 110 includes a switch 112, a NAT table 114, and a checksumcalculation module (checksum module) 116. In operation, NAT router 110receives IP packets, translates the information included in a sourcefield and in a port field of the IP packets to new source informationand new port information based upon the entries in NAT table 114,calculates a new checksum for the IP packets based upon the new sourceinformation and the new port information in checksum module 116, andforwards the IP packets to a destination indicated by a destinationfield of the IP packets via switch 112. FIG. 1 illustrates a particularexample where an IP packet 140 is provided from client 120, istranslated by NAT router 110, and a translated IP packet 150 is providedto public network 130, as described below. The skilled artisan willrecognize that NAT router 110 will operate similarly when IP packets arereceived from clients 122 and 124 for forwarding to public network 130,and when IP packets are received from the public network for forwardingto the clients, and as such, specific examples of the operation of theNAT router will not be further described herein.

NAT table 114 includes entries for each of clients 120, 122, and 124, asdefined b their respective private IP addresses and assigned privateports. For example, NAT table 114 includes an entry for client 120 thatis referenced by the private IP address of the client, that is,192.168.100.2, and by the private port assigned to the client, that is,port 3855. For each client entry, NAT table 114 includes an associatedpublic IP address, that is, the public IP address of NAT router 110,143.166.147.7, and an assigned public port, that is, port 6282. When anIP packet is received from the private network, the source informationincluded in a source field of the IP packet, that is, the private IPaddress and the private port, is replaced with the public sourceinformation, that is, the public IP address and the public port.Conversely, when an IP packet is received from the public network, thedestination information included in a destination field of the IPpacket, that is, the public IP address of NAT router 110 and the publicport associated with a particular client 120, 122, or 124, is replacedwith the private destination information, that is the private IP addressand the private port of the particular client.

However, in both the case of the IP packet received from the privatenetwork and the case of the IP packet received from the public network,the translated data packet that is forwarded via switch 112 requires thecalculation of an updated checksum. That is, if the original checksum asfound in the received IP packet and that is based upon the originalsource or destination information, is provided on an IP packet that hashad a source field or destination field translated, the translated IPpacket will be identified as a bad packet because the receiving devicewill calculate a different checksum based upon the translated source ordestination information. Therefore, after translating the source ordestination field of received IP packets, checksum module 116 operatesto calculate a new checksum based upon the contents of the translatedsource field or destination field.

In the illustrated example, NAT router 110 receives IP packet 140 fromclient 120. IP packet 140 includes a source address field 142, adestination address field 144, a data payload 146, and a checksum field148. Source field 142 includes the IP address and the port informationassociated with client 120, that is, IP address 192.168.100.2 and port3855. Destination field 144 includes that IP address and the portinformation associated with the destination to which the information indata payload 146 is intended to be delivered, such as IP address143.166.224,244 and port 80. Checksum field 148 includes checksuminformation for data packet 140 that is determined based upon theinformation in source field 142, destination field 144, and data payload146.

NAT router 110 translates IP packet 140 into anew IP packet 150including new source field 152, destination field 144, data payload 146,and a new checksum field 158, as follows. NAT router 110 determines thatIP packet 140 is from client 120 based upon the information in sourcefield 142, indexes into NAT table 114 to determine the public addressassociated with the client, and provides the public address informationfrom the NAT table to new source field 152. No translation ormodification is performed on the contents of destination field 144 ordata payload 146, so the destination field and the data payload areprovided to IP packet 150.

Checksum module 116 operates to determine a new checksum for data packet150 and to provide the new checksum in checksum field 158, therebycompleting the translation of IP packet 140, and switch 112 routes datapacket 150 to the destination in public network 130. In a particularembodiment, checksum module 116 determines the new checksum based uponthe contents of new source field 152, destination field 144, and datapayload 146. In another embodiment, checksum module 116 determined thenew checksum based upon the checksum information from checksum field 148and the source information from new source field 152, without referenceto the information in destination field 144 or data payload 146.Checksum module 116 calculates the checksum information based upon oneor more checksum algorithms, as described below. In a particularembodiment, NAT router 110 includes a processor and a memory, andchecksum module 116 represents code stored in the memory for performingthe one or more checksum algorithms. In another embodiment, checksummodule 116 represents a hardware device configured to perform the one ormore checksum algorithms, such as an application specific integratedcircuit, a programmable logic device, or another hardware device, asneeded or desired. The skilled artisan will recognize that for a givenIP packet, the payload may include other types of packets such asTransmission Control Protocol (TCP) packets, User Datagram Protocol(UDP) packets, or other packets that may include their own checksumvalidation. The teachings of the present disclosure are applicable asdescribed below.

In a particular embodiment, checksum module 116 operates to performupdates of checksums for IP packets, TCP packets, and UDP packets inaccordance with the Internet Engineering Task Force (IETF) Request ForComments Number 1624 (RFC 1624) which describes a technique forincremental computation of Internet packet checksums using unsignedtwos-complement arithmetic. For IP and TCP packets, the checksum updateproceeds according to the following pseudo-code:

TABLE-US-00001   // x = original checksum // d = is the difference ((m −m') in 16-bit ones- complement arithmetic) // m = original data // m' =new data // x1 = new checksum in least significant 16-bits x1 = (x{circumflex over ( )} 0xffff) + d; if (x1 > 0xffff) x1 = x1 − 0xffff; x1= x1 {circumflex over ( )} 0xffff;

FIG. 2 illustrates a method of determining IP and TCP packet checksumupdates in accordance with ITEF RFC 1624, starting at block 202. Inblock 204, the checksum information from the packet is complemented. Inblock 206, the difference in the header information is added to thecomplemented checksum. Here, in is the original header information andm′ is the new header information. The skilled artisan will recognizethat, using ones-complement arithmetic, the operation (m−m′) isequivalent to the operation (.about.m+m′). A decision is made as towhether or not the result from block 206 is greater than 65,535 (0xffff)in decision block 208. This decision determines whether, for a 16-bitchecksum, the operation of block 206 resulted in an overflow. If so, the“YES” branch of decision block 208 is taken, one is added to the resultfrom block 206 in block 210, the result from block 210 is complementedin block 212 to determine the checksum, and the method ends in block214. If the result from block 206 is not greater than 65,535, the “NO”branch of decision block 208 is taken, the result from block 206 iscomplemented in block 212 to determine the checksum, and the method endsin block 214.

For UDP packets in which the checksum is not equal to zero, the checksumupdate proceeds according to the following pseudo-code:

TABLE-US-00002   // x =original checksum // d = is the difference ((m −m') in 16-bit ones- complement arithmetic) // m = original data // m' =new data // x1 = new checksum in least significant 16-bits x1 = (x{circumflex over ( )} 0xffff) + d; if (x1 > 0xffff) x1 = x1 − 0xffff; x1= x1 {circumflex over ( )} 0xffff; if (x1 == 0) x1 = 0xffff;

FIG. 3 illustrates a method of determining UDP packet checksum updatesin accordance with ITEF RFC 1624, starting at block 302. In block 304,the checksum information from the packet is complemented. In block 306,the difference in the header information is added to the complementedchecksum. A decision is made as to whether or not the result from block306 is greater than 65,535 (0xffff) in decision block 308. If so, the“YES” branch of decision block 308 is taken, one is added to the resultfrom block 306 in block 210, and the result from block 310 iscomplemented in block 312. If the result from block 306 is not greaterthan 65,535, the “NO” branch of decision block 308 is taken and theresult from block 306 is complemented in block 312. A decision is madeas to whether or not the least significant 16 bits of the result fromblock 312 is equal to zero in decision block 314. If not, the “NO”branch of decision block 314 is taken, the new checksum is the resultfrom block 312, and the method ends in block 214. If the leastsignificant 16 bits of the result from block 312 is equal to zero, the“YES” branch of decision block 314 is taken, the checksum is set toequal 65535 (0xffff) in block 316, and the method ends in block 318.

In another embodiment, checksum module 116 operates to perform updatesof checksums for IP packets, TCP packets, and UDP packets usingtwos-complement arithmetic. For IP and TCP packets, the checksum updateproceeds using unsigned twos-complement arithmetic according to thefollowing pseudo-code:

TABLE-US-00003   // x = original checksum // d = is the difference ((m −m') in 16-bit ones- complement arithmetic) // m = original data // m' =new data // x1 = new checksum in least significant 16-bits x1 = x − d;if (x1 > 0xffff) x1 = x1 − 1;

FIG. 4 illustrates a method of determining IP and TCP packet checksumupdates in accordance with the present disclosure, starting at block402. In block 404, the difference in the header information issubtracted from the checksum. A decision is made as to whether or notthe result from block 404 is greater than 65,535 (0xffff) in decisionblock 406. If so, the “YES” branch of decision block 406 is taken, oneis subtracted from the result from block 404 to provide the checksum inblock 408 and the method ends in block 410. If the result from block 404is not greater than 65,535, the “NO” branch of decision block 406 istaken, the checksum is the result from block 404, and the method ends inblock 410.

For UDP packets in which the checksum is not equal to zero, the checksumupdate proceeds using unsigned twos-complement arithmetic according tothe following pseudo-code:

TABLE-US-00004   // x = original checksum // d = is the difference ((m −m') in 16-bit ones- complement arithmetic) // m = original data // m' =new data // x1 = new checksum in least significant 16-bits x1 = x + d;if (x1 > 0xffff) x1 = x1 + 1;

FIG. 5 illustrates a method of determining UDP packet checksum updatesin accordance with the present disclosure, starting at block 502. Inblock 504, the difference in the header information is added to thechecksum. A decision is made as to whether or not the result from block504 is greater than 65,535 (0xffff) in decision block 506. If so, the“YES” branch of decision block 506 is taken, one is added to from theresult from block 504 to provide the checksum in block 508 and themethod ends in block 510. If the result from block 504 is not greaterthan 65,535, the “NO” branch of decision block 506 is taken, thechecksum is the result from block 504, and the method ends in block 510.

In a particular embodiment, the checksum updates as described herein areprovided on other types of devices that perform checksum updates, inaddition to the embodiment shown for NAT router 110. For example, wherea network router, switch, gateway, firewall, intrusion detection system,intrusion prevention system, perimeter network, or other device operatesto calculate IP packet checksums, the teachings of the presentapplication can be utilized to provide the checksums, and theillustration of NAT router 110 is provided as an exemplary embodiment ofthe present disclosure. For example, calculation of the checksuminformation included in checksum field 148 can be performed in client120 based upon the teachings of the present application, using theinformation from source address field 142, destination address field144, and data 146.

FIG. 6 illustrates a generalized embodiment of information handlingsystem 600. For purpose of this disclosure information handling system600 can include any instrumentality or aggregate of instrumentalitiesoperable to compute, classify, process, transmit, receive, retrieve,originate, switch, store, display, manifest, detect, record, reproduce,handle, or utilize any form of information, intelligence, or data forbusiness, scientific, control, entertainment, or other purposes. Forexample, information handling system 600 can be a personal computer, alaptop computer, a smart phone, a tablet device or other consumerelectronic device, a network server, a network storage device, a switchrouter or other network communication device, or any other suitabledevice and may vary in size, shape, performance, functionality, andprice. Further, information handling system 600 can include processingresources for executing machine-executable code, such as a centralprocessing unit (CPU), a programmable logic array (PLA), an embeddeddevice such as a System-on-a-Chip (SoC), or other control logichardware. Information handling system 600 can also include one or morecomputer-readable medium for storing machine-executable code, such assoftware or data. Additional components of information handling system600 can include one or more storage devices that can storemachine-executable code, one or more communications ports forcommunicating with external devices, and various input and output (I/O)devices, such as a keyboard, a mouse, and a video display. Informationhandling system 600 can also include one or more buses operable totransmit information between the various hardware components.

Information handling system 600 can include devices or modules thatembody one or more of the devices or modules described above, andoperates to perform one or more of the methods described above.Information handling system 600 includes a. processors 602 and 604, achipset 610, a memory 620, a graphics interface 630, include a basicinput and output system/extensible firmware interface (BIOS/EFI) module640, a disk controller 650, a disk emulator 660, an input/output (I/O)interface 670, and a network interface 680. Processor 602 is connectedto chipset 610 via processor interface 606, and processor 604 isconnected to the chipset via processor interface 608. Memory 620 isconnected to chipset 610 via a memory bus 622. Graphics interface 630 isconnected to chipset 610 via a graphics interface 632, and provides avideo display output 636 to a video display 634. In a particularembodiment, information handling system 600 includes separate memoriesthat are dedicated to each of processors 602 and 604 via separate memoryinterfaces. An example of memory 620 includes random access memory (RAM)such as static RAM (SRAM), dynamic RAM (DRAW non-volatile RAM (NV-RAM),or the like, read only memory (ROM), another type of memory, or acombination thereof.

BIOS/EFI module 640, disk controller 650, and I/O interface 670 areconnected to chipset 610 via an I/O channel 612. An example of I/Ochannel 612 includes a Peripheral Component Interconnect (PCI)interface, a PCI-Extended (PCI-X) interface, a high-speed PCI-Express(PCIe) interface, another industry standard or proprietary communicationinterface, or a combination thereof. Chipset 610 can also include one ormore other I/O interfaces, including an Industry Standard Architecture(ISA) interface, a Small Computer Serial Interface (SCSI) interface, anInter-Integrated Circuit (I.sup.2C) interface, a System Packet Interface(SPI), a Universal Serial Bus (USB), another interface, or a combinationthereof. BIOS/EFI module 640 includes BIOS/EFI code operable to detectresources within information handling system 600, to provide drivers forthe resources, initialize the resources, and access the resources.BIOS/EFI module 640 includes code that operates to detect resourceswithin information handling system 600, to provide drivers for theresources, to initialize the resources, and to access the resources.

Disk controller 650 includes a disk interface 652 that connects the disccontroller to a hard disk drive (HDD) 654, to an optical disk drive(ODD) 656, and to disk emulator 660. An example of disk interface 652includes an Integrated Drive Electronics (IDE) interface, an AdvancedTechnology Attachment (ATA) such as a parallel ATA (PATA) interface or aserial ATA (SATA) interface, a SCSI interface, a USB interface, aproprietary interface, or a combination thereof. Disk emulator 660permits a solid-state drive 664 to be connected to information handlingsystem 600 via an external interface 662. An example of externalinterface 662 includes a USB interface, an IEEE 1394 (Firewire)interface, a proprietary interface, or a combination thereof.Alternatively, solid-state drive 664 can be disposed within informationhandling system 600.

I/O interface 670 includes a peripheral interface 672 that connects theI/O interface to an add-on resource 674, to a TPM 676, and to networkinterface 680. Peripheral interface 672 can be the same type ofinterface as I/O channel 612, or can be a different type of interface.As such, I/O interface 670 extends the capacity of I/O channel 612 whenperipheral interface 672 and the I/O channel are of the same type, andthe I/O interface translates information from a format suitable to theI/O channel to a format suitable to the peripheral channel 672 when theyare of a different type. Add-on resource 674 can include a data storagesystem, an additional graphics interface, a network interface card(NIC), a sound/video processing card, another add-on resource, or acombination thereof. Add-on resource 674 can be on a main circuit board,on separate circuit board or add-in card disposed within informationhandling system 600, a device that is external to the informationhandling system, or a combination thereof.

Network interface 680 represents a NIC disposed within informationhandling system 600, on a main circuit board of the information handlingsystem, integrated onto another component such as chipset 610, inanother suitable location, or a combination thereof. Network interfacedevice 680 includes network channels 682 and 684 that provide interfacesto devices that are external to information handling system 600. In aparticular embodiment, network channels 682 and 684 are of a differenttype than peripheral channel 672 and network interface 680 translatesinformation from a format suitable to the peripheral channel to a formatsuitable to external devices. An example of network channels 682 and 684includes InfiniBand channels, Fibre Channel channels, Gigabit Ethernetchannels, proprietary channel architectures, or a combination thereof.Network channels 682 and 684 can be connected to external networkresources (not illustrated). The network resource can include anotherinformation handling system, a data storage system, another network, agrid management system, another suitable resource, or a combinationthereof.

Although only a few exemplary embodiments have been described in detailherein, those skilled in the art will readily appreciate that manymodifications are possible in the exemplary embodiments withoutmaterially departing from the novel teachings and advantages of theembodiments of the present disclosure. Accordingly, all suchmodifications are intended to be included within the scope of theembodiments of the present disclosure as defined in the followingclaims. In the claims, means-plus-function clauses are intended to coverthe structures described herein as performing the recited function andnot only structural equivalents, but also equivalent structures.

The above-disclosed subject matter is to be considered illustrative, andnot restrictive, and the appended claims are intended to cover any andall such modifications, enhancements, and other embodiments that fallwithin the scope of the present invention. Thus, to the maximum extentallowed by law, the scope of the present invention is to be determinedby the broadest permissible interpretation of the following claims andtheir equivalents, and shall not be restricted or limited by theforegoing detailed description.

What is claimed is:
 1. A system for updating data packet checksums, thesystem comprising: a communication interface that receives a data packetvia a first port, wherein the received data packet includes first sourcefield information and first port field information; and a processor thatexecutes instructions stored in memory, wherein execution of theinstructions by the processor: identifies second source fieldinformation and second port field information for the data packet basedon the first source field information and first port field information,the identified second source field information and the second port fieldinformation associated with a second port; calculates a checksum basedon the second source field information and second port fieldinformation; and updates the received data packet based on thecalculated checksum; wherein the communication interface forwards theupdated data packet to a destination via a second port.
 2. The system ofclaim 1, wherein the updated data packet further includes a destinationfield identifying an internet protocol (IP) address and a data payloadfield, the IP address identifying the destination to which dataindicated by the data payload field is to be delivered.
 3. The system ofclaim 2, wherein the communication interface further forwards theupdated data packet to the destination.
 4. The system of claim 2,wherein the checksum is further calculated based on the destinationfield and the data payload field.
 5. The system of claim 1, wherein thechecksum is calculated further based on twos-complement arithmetic. 6.The system of claim 5, wherein the twos-complement arithmetic comprises:x1=x−d;if (x1>Oxffff)x1=x1−1; & Oxffff; where x is an original checksum calculated from thefirst source field information and first port field information, d is aones-complement difference (m−m′) between first data (m′) associatedwith the checksum and second data (m) associated with the originalchecksum, and wherein x1 is the checksum.
 7. The system of claim 1,wherein the received data packet is at least one of an IP data packet,transmission control protocol packet, and a user datagram protocolpacket.
 8. A method for updating data packet checksums, the methodcomprising: receiving a data packet at a communication interface via afirst port, the received data packet including first source fieldinformation and first port field information; executing instructionsstored in memory, wherein execution of the instructions by a processor:identifies second source field information and second port fieldinformation for the data packet based on the first source fieldinformation and first port field information, the identified secondsource field information and the second port field informationassociated with via a second port; calculates a checksum based on thesecond source field information and second port field information; andupdates the received data packet based on the calculated checksum; andforwarding the updated data packet to a destination via a second port.9. The method of claim 8, wherein the updated data packet furtherincludes a destination field identifying an IP address and a datapayload field, the IP address identifying the destination to which dataindicated by the data payload field is to be delivered.
 10. The methodof claim 9, wherein the checksum is further calculated based on thedestination field and the data payload field.
 11. The method of claim 9,wherein the checksum is calculated further based on twos-complementarithmetic.
 12. The method of claim 11, wherein the twos-complementarithmetic comprises:x1=x−d;if (x1>Oxffff)x1=x1−1; & Oxffff; where x is an original checksum calculated from thefirst source field information and first port field information, d is aones-complement difference (m−m′) between first data (m′) associatedwith the checksum and second data (m) associated with the originalchecksum, and wherein x1 is the checksum.
 13. The method of claim 8,wherein the received data packet is at least one of an IP data packet,transmission control protocol packet, and a user datagram protocolpacket.
 14. A non-transitory computer-readable storage medium, havingembodied thereon instructions executable by at least one processor toperform a method for updating data packet checksums, the methodcomprising: receiving a data packet at a communication interface via afirst port, the data packet including first source field information andfirst port field information; identifying second source fieldinformation and second port field information for the data packet basedon the first source field information and first port field information,the identified second source field information and the second port fieldinformation associated with a second port; calculating a checksum basedon the second source field information and second port fieldinformation; updating the received data packet based on the calculatedchecksum; forwarding the updated data packet to a destination via asecond port.
 15. The non-transitory computer-readable storage medium ofclaim 14, wherein the updated data packet further includes a destinationfield identifying an IP address and a data payload field including data,the IP address identifying the destination to which data indicated bythe data payload field is to be delivered.
 16. The non-transitorycomputer-readable storage medium of claim 15, further comprisinginstructions executable to forward the updated data packet to thedestination.
 17. The non-transitory computer-readable storage medium ofclaim 15, wherein the checksum is calculated after the first sourcefield information and second source field information have beendetermined and the checksum is further calculated based on thedestination field and the data payload field.
 18. The non-transitorycomputer-readable storage medium of claim 14, wherein the checksum iscalculated further based on twos-complement arithmetic.
 19. Thenon-transitory computer-readable storage medium of claim 18, wherein thetwos-complement arithmetic comprises:x1=x−d;if (x1>Oxffff)x1=x1−1; & Oxffff; where x is an original checksum calculated from thefirst source field information and first port field information, d is aones-complement difference (m−m′) between first data (m′) associatedwith the checksum and second data (m) associated with the originalchecksum, and wherein x1 is the checksum.